A transient network or database error during the background heartbeat will cause renewLease() to throw an exception. Currently, the .catch(() => { leaseLost = true }) block on the heartbeat interval catches any error and permanently sets leaseLost = true. This will prematurely abort the entire wake process even if the network recovers immediately and the lease hasn't actually expired or been claimed by another daemon.

We should only set leaseLost = true if the lease is definitely lost (i.e., when renewClarificationWake returns false and throws ClarificationWakeLeaseLostError). Other transient errors should be logged and retried on the next heartbeat tick.

    const heartbeat = setInterval(() => {
      if (renewalInFlight || leaseLost) return
      renewalInFlight = true
      void renewLease()
        .catch((error) => {
          if (error instanceof ClarificationWakeLeaseLostError) {
            leaseLost = true
          } else {
            this.#logger.warn?.('[factory] transient error renewing clarification wake lease', error)
          }
        })
        .finally(() => { renewalInFlight = false })
    }, Math.max(1_000, Math.floor(CLARIFICATION_WAKE_LEASE_MS / 3)))

Addressed in 75db518. The heartbeat now treats only ClarificationWakeLeaseLostError as confirmed ownership loss; transient state-store errors are logged and retried on later heartbeats. Explicit renewals around resume, spawn, injection, and completion still fail closed. Added a timed blocked-resume regression that injects one transient background renewal failure and proves the team completes its wake without a lease-loss event. Full suite: 696/696.

The #releaseAgentsForClarification method fetches the fleet roster multiple times inside the loop (both before and after releasing each agent) and once more at the end. Since fetching the roster typically involves an external API call or container orchestrator query, doing this repeatedly can be highly inefficient and slow down the release process.

We can optimize this by fetching the roster once at the start of the method, updating our local online set as we release agents, and only re-fetching the roster when an agent is actually released to verify its status.

  async #releaseAgentsForClarification(key: string, agents: Array<[string, TrackedAgent]>): Promise<void> {
    let waiting = await this.#state.getWaitingClarification(this.#workspaceId, key)
    if (!waiting) return
    const roster = await this.#fleet.roster()
    let online = new Set(roster.agents.map((agent) => agent.name))

    for (const [name, tracked] of agents) {
      if (waiting.releasedAgents?.includes(name) && !online.has(name)) continue
      try {
        // Prefer broker release over process termination so the harness gets a
        // graceful shutdown boundary and can flush its latest resumable state.
        await this.#fleet.release(name, 'waiting-for-human')
      } catch (error) {
        this.#logger.warn?.('[factory] graceful clarification release failed; forcing local teardown', {
          agentName: name,
          error,
        })
        await this.#releaseAndTerminateAgents([[name, tracked]], 'waiting-for-human', 'clarification')
      }
      const onlineAfter = new Set((await this.#fleet.roster()).agents.map((agent) => agent.name))
      if (onlineAfter.has(name)) {
        throw new Error(`fleet still reports ${name} online after clarification release`)
      }
      online = onlineAfter
      waiting = await this.#state.markClarificationAgentReleased(this.#workspaceId, key, name) ?? waiting
    }

    // Check the whole snapshot once more before opening the wake gate. This
    // catches server-side restart policies that re-register a name between its
    // individual release confirmation and the final parked transition.
    const stillOnline = agents.map(([name]) => name).filter((name) => online.has(name))
    if (stillOnline.length > 0) {
      throw new Error(`clarification agents still online: ${stillOnline.join(', ')}`)
    }
  }

Optimized in 75db518. The method now takes one initial roster snapshot and refreshes it only after an actual release, eliminating the redundant pre-release query for each agent. I deliberately retained the final independent roster fetch: reusing the last per-agent snapshot would miss an earlier agent re-registering between its checkpoint and the parked transition, which is a core safety invariant for this issue.

P1: A claimed Slack answer can remain permanently parked after a daemon crash because this line durably records reply before the wake lease is claimed. Startup recovery would be safer if it drained persisted replies or atomically persisted the reply and wake intent instead of skipping records that already contain waiting.reply.

Check if this issue is valid — if so, understand the root cause and fix it. At src/state/file-state-store.ts, line 140:

<comment>A claimed Slack answer can remain permanently parked after a daemon crash because this line durably records `reply` before the wake lease is claimed. Startup recovery would be safer if it drained persisted replies or atomically persisted the reply and wake intent instead of skipping records that already contain `waiting.reply`.</comment>

<file context>
@@ -71,9 +77,273 @@ export class FileStateStore extends InMemoryStateStore {
+        if (!record || record.reply) {
+          return undefined
+        }
+        record.reply = { ...reply }
+        await this.#persist(document)
+        return cloneClarification(record)
</file context>

The reported permanent-park path was not present: startup and the run loop already drain durable records containing reply even without a new Slack event. I added the exact crash-window regression in 6844d1a: it seeds a fully parked FileStateStore record with a persisted reply but no wake lease, constructs a fresh factory with no new Slack event, and proves startup resumes/injects the team exactly once and clears the record.